feat: pin HARICA ECC roots, explain the trust model, and fix the autoconnect race - #111

Een verouderde pin zag eruit als een vastloper: NetworkManager bleef
proberen en nergens op het scherm stond dat het certificaat de oorzaak
was. Precies waarom #109 zo lang onverklaard bleef.

Faalt de activatie, dan leest het script nu de journal terug op
certificaatfouten. Vindt het die, dan toont het de fout, de keten die de
server werkelijk stuurde, en wat er moet gebeuren: meld de keten, en
gebruik --ignore-certificate om intussen te verbinden. Zonder journal-
toegang valt het terug op het commando dat de gebruiker zelf kan draaien.

Verder twee dingen overgenomen uit het CAT-installatiescript van GEANT:

  connection.permissions  het profiel is van wie het script draaide, niet
                          van elk account op de machine
  802-1x.auth-timeout     begrenst hoelang NetworkManager op een
                          vastgelopen EAP-uitwisseling blijft wachten

Trust-on-first-use is bewust niet gebouwd. Dat zou de eerste verbinding
laten leunen op de systeem-truststore, ongeveer 150 CA's, waar de
officiele CAT-methode er twee vertrouwt. Ruimer dan wat Saxion
voorschrijft, en dat is de grens die we niet overgaan.

Vier roots in plaats van twee. Het RSA-paar is wat de server vandaag
stuurt; het ECC-paar staat er voor als Saxion van RSA afstapt, zodat die
overstap dit script niet breekt. Alle vier komen uit het Mozilla
root-programma en zijn op SHA-256 geidentificeerd, niet op naam - zoals
HARICA TLS RSA Root CA 2021 laat zien, waarvan de self-signed en
cross-signed vorm dezelfde CN dragen maar verschillende certificaten
zijn.

Dialogen kiezen nu de toolkit die bij het bureaublad past. Op KDE staat
vaak zenity geinstalleerd als afhankelijkheid van iets anders, en dan
kreeg je een GTK-venster op een Qt-bureaublad. kdialog gaat daar nu voor,
zenity elders.

Python-eis van 3.10 naar 3.11, met een controle bij het starten zodat de
eis ook echt iets betekent. Dit is een ondersteuningskeuze, geen
technische: de code draait op oudere versies, maar alles wat actueel is
levert 3.11 of nieuwer.

De documentatie klopte op zeven punten niet meer. Belangrijkste: er stond
dat de officiele installer vastloopt door wijzigingen in NetworkManager.
Dat is niet zo, en we weten inmiddels beter - het is de verouderde CA in
hun profiel. Verder de vier roots, de vlaggen, de afhankelijkheden (geen
enkele buiten de standaardbibliotheek), en dat het handmatige nmcli-recept
naar een CA-bestand verwijst dat pas bestaat nadat het script gedraaid
heeft.

De vier gepinde roots zijn geverifieerd tegen HARICA's eigen repository
op repo.harica.gr. Alle vier de SHA-1 fingerprints kwamen overeen met de
bytes in dit script. Daarmee is de keten rond: geen enkele root staat
erin omdat een handshake hem aanbood, maar omdat de CA-operator hem
publiceert.

Het commentaarblok legt nu uit welke bron welke rol speelt. CAT levert de
verbindingsparameters, en die kloppen; alleen hun CA niet, en dat is
precies issue #109. De handshake vertelt welke roots in gebruik zijn.
HARICA levert de certificaten zelf. Geen van drieen wordt op zichzelf
vertrouwd.

Uit HARICA's repository blijkt ook dat het cross-certificaat op
2029-08-31 verloopt. Daarna moet de keten eindigen bij de self-signed
2021-root, die hier al vastligt. Die overgang is dus geregeld, en dat is
geen aanname meer maar een datum.

De documentatie krijgt in beide talen een sectie waarmee lezers dit zelf
kunnen natrekken: de fingerprints van HARICA ernaast, plus een commando
dat toont wat er daadwerkelijk op hun machine staat. Dat commando is
gedraaid en geeft exact de vier waarden uit de tabel.

Vijftien em-dashes op de installatiepagina's, waarvan elf van mij. Het
leest als een tic en niet als de rest van de site. Vervangen door punten,
komma's en dubbele punten, zonder dat er betekenis verandert.

Ook de ene in het script zelf, in de melding dat het profiel bewaard is.